ブロックチェーン技術概論 理論と実践
本の紹介
専門科目の教科書を想定して、講義の15回に合わせている
1 - 6章
ブロックチェーンの基礎
復習項目
chapter4 暗号技術に対して数学的な解説、わかりやすい
標準が決まっていない暗号もあるよ
7 - 12章
社会実装のための機能、水準
実際運用技術の上で重要だからやる必要がある
高度な内容も含む
13 - 15章
企業での活用、開発、運用方法について
さらっとで良さそう
電子署名は以下を満たす必要がある
完全性
真正性
ビットコインのブロードキャスト
論文にも記載あり
日本語で放送
前ノードにトランザクションのメッセージを送信すること
ビットコインのノード間の通信そのものはTCPのユニキャスト通信で行っている
-> ここがTCPを使っているポイント
各ノードは自分が受け取ったメッセージを、10本の外向けリンクを通じて隣接ノードにリレーする
どのようにして電子認証局 CA を信用するのか？
ブロックチェーンではCAは不要
公開鍵そのものが当事者を識別する情報
秘密鍵を知っていることが本人であることの証明
UTXOのアンロックには秘密鍵ではなく秘密鍵によって署名されたデジタル署名が必要
コンセンサスプロトコルがやっているのは
全てのノードが1つの状態の共有台帳に合意させること
NIST NISTIR 8202 blockchain technology overview
ブロックチェーンを使うべき条件
p28
https://scrapbox.io/files/657e22b97d93770023c11ce2.jpghttps://scrapbox.io/files/657e22c0e0f1650024d0afc7.jpg
それ以降に標準はないのか？
トラスト
ビットコインの目的はトラストサービスプロバイダー, TSPを不要にすること
誰かに信頼を仲介してもらうことを不要にする
例えば、銀行に個人情報や金融資産を委託するとか、GAFAに個人情報やメアドを委託するとか
リードホフマンはトラストレスなトラスト
ブロックチェーンは信頼しているけど、他のネットワーク参加者の誰も信頼していない
これは従来にはない
無料ではない
ヴラド問題
国家の法規制 vs ブロックチェーンと対立していて、一致していない
permissoned blockchainによるアクセス制御よりもprimary node、審判をするノードの配置や役割を考える方が、スループットやスケラビリティに貢献する
ニックサボのスマートコントラクトの基本原則
ブロックチェーンのスマートコントラクトではない、本当の契約に近い
観測可能性, observability
契約の履行状況がわかるか
客観的検証可能性, verfiability
仲裁者に証明できるか、または、仲裁者が検証できるか
契約当事者関係, privity
仲裁者以外の第三者は口出しできないこと
強制力, enforceability
インセンティブや罰金なども含む
p57
EthereumはビットコインのUTXOモデルの問題を解決
どんな問題があるのか詳しく教えて？
Ethereumはどのように現在の残高を計算しているの？
ライトニングネットワークがファイナリティの不可逆性の問題を解決しているの？
p69
等価安全性のグラフ
p74
https://scrapbox.io/files/657e23139bb1990023f3f3a7.jpg
2031年以降は128ビット安全性よりも強い強度を
攻撃手法が生み出されたら
192ビット安全性以上の安全性はいらない、非合理的かなと考えられている
zk-snarksの論文
zk + 計算量的健全性を持つ知識の証明系
2013
933の引用
Quadratic Span Programs and Succinct NIZKs without PCPs
実装はzcashが起源？
ショアのアルゴリズム
楕円曲線離散対数問題を効率的に解く
ビットコインはビットコインにおけるスマートコントラクトを駆動するためのオラクルとしての時間を暗号学的ハッシュ関数という神託機械いよって供給し続けているシステムとしてみなすことができる
p180
イーサリアムのピア選択プロセス
ビットコインのマークルツリー
ツリーの各ノードが2つの子ノードを持つバイナリツリーで、これはリスト形式のデータを圧縮、認証するのにとても優れたデータ構造
gethはlevelDBを使用
Secure Foundatin Architecture, SeF
フルノードのストレージコストを分散できるようにする
フルノードの負担軽減と新規参加ノードのサポートを消失訂正符号を使ってうまく両立させるというアプローチ
まだブロックチェーンで実装されたことはない
lightning network
BOLT, basis of lightning technologyが一番使われている
取引相手となるユーザーとの間にペイメントチャネルが直接解説されていない場合でも、取引当事者同士を間接的に繋ぐペイメントチャネルを持つユーザが存在すれば、このユーザを経由して取引ができる
HTLC, Hashed Time Lock Contractを実装
期間内に取引が行われなかったら送信元に資産を戻す約束をする機能
OSSリスト
c-lightning
blockstream社
Lnd
Lightning Labs社
eclair
ACINQ社
Prarmigan
Nayuta社
日本
DLC, Discreet Log Contracts
オラクルを使ってスマートコントラクト実行するために署名検証できるようにしたプロトコル
Schnorr署名を使ってビットコインでオラクルを利用してコントラクトを実行できるように
署名データがそのままオンチェーン上で評価されることはない
当事者以外わからない
プライバシーの向上
DECO, Decentralized Oracle
プライバシーデータを利用した認証機能
TLSで保護されたWebsiteのデータを分散オラクルとして利用できる
できること
プライベートデータを利用したコントラクトの実行
オラクルサービスが提供していないデータでもWebサイトで提供されているデータを利用したコントラクトの実行
DECO: Liberating Web Data Using Decentralized Oracles for TLS
コーネル大学
ユーザは、証明したい暗号データが、あるTLSサーバからの情報であることを証明し、暗号データを複合する、ゼロ知識で暗号デーの元の平文に関するステートメントを証明することで、任意のwebサイトを分散オラクルとして利用できる
https://scrapbox.io/files/657e11cb854a4e002410abad.jpg
通常、3の第三者の検証者にその通信データの真正性を証明できない
TLSが暗号化するから
DECOでは
マルチパーティ計算を使用してオラクルとユーザ間のTLSセッションデータを安全に共有し、ゼロ知識証明を使用してユーザがTLSセッションデータの内容についてオラクルに証明できるようにしている
やすくするために、暗号化データの一部を部分的に開示して、それが暗号化される前の平文のチャンクの一部であることを証明している
証明の流れp243
Schnorr署名
ECDSAと異なり、署名データに線形性があり、署名技術だけでn-of-nのマルチシグを作れる
これでアカウントログインみたいなこともできるんかな？
部長クラスがいないとデータにアクセスできないようにするみたいな感じで
信頼できない相手とのマルチシグをするときは、
Rogue-key攻撃に気をつけて
Musigが耐性ある
署名生成時の参加者間のラウンド減らす方式
これらを使っても決定性署名使用の問題が残る
2回のセッションで秘密鍵を知られるリスク？
MuSig-DN, Determisitic Noncesという決定性署名をサポートする署名方式もある
相手のpublci nonceが決まったルールの下で導出された値であることをゼロ知識証明を使って検証できるようにする
zkの高コストな計算が必要
今はmusigの方が良い
ミキシング
複数の送信者の送金を1つのtxにミックスすることで、どのコインがどのアドレスに送金されたかを難読化する
プライバシーの向上
Coinjoin
p2pミキシング
サードパーティの信頼が必要
インプットとアウトプットのコイン量にばらつきがあると結局わかる
精密にすると参加者が集まりにくい = 時間がかかるということ？
最適な数字は検証されいないのか、誰か論文教えて？
ミキサーがインプットとアウトプットの関係性を知ってしまう
Chaumian Coinjoin
ミキサーがインプットとアウトプットの関係性を知ってしまうを解決
ブラインド署名
chaumのブラインド署名から名前の由来
utxoの所有証明はdos攻撃耐性にもなる
先行事例あり
ビットコイン上の、wasabi wallet samourai wallet
payjoin
utxoごとミックスしちゃえ！
BTC pay server, wasabi walletがサポート
プライバシー向上
utxoセットの膨張も防ぐ
送金量の秘匿化
機密トランザクション, confidential tx
Bulletproofs
暗号プリミティブ
アウトプットのサイズが2KBよりも小さいはず？
リング署名も使う
trusted setupが不要
monero以外にもmimblewimble系の暗号通貨であるグリンやビームでも導入、どういう意味やそれ
送信者の秘匿
LSAG, Linkable spontaneous anonymous group signatures
3つの特性がある
署名者の曖昧さ
観察者（検証者でもあっている？）は公開鍵のセットのどれかに対応する秘密鍵で署名されたか検証できるけど、どのメンバーによるものかはわからない
公開鍵が多いほど良いね
スケーリングとの戦い
2020年10月時点でモネロは11のリングサイズを使用
リンク可能性 linkability
同じ秘密鍵を使って異なる2つのメッセージに署名した場合、その2つの署名はリンクされる
UTXOの二重使用を防ぐ
重複するキーイメージが使われていないかをチェックする
キーイメージは署名に使用する鍵ペアから生成される
偽造不可能性
RingCT
confidential txも実装
リング署名必要
MLSAG, Multi-layered linkable spontaneous anonymous groupの改良として2020年10月には
署名データサイズをさらに削減
CLSAG, Concise linkable spontaneous anonymous groupを実装
送金内容の秘匿化
おなじみzk-snarks
zcashのsaplingは40MB
当初は40秒以上かかる、3GB
trusted setup必要
ここで共通参照文字列 CRS を生成
マルチパーティ計算でCRSを生成
zkpを実装するときに重要なこと
証明の生成にかかるコスト
証明の検証にかかるコスト
証明のサイズ
trusted setupの有無
量子耐性の有無
経路の秘匿化
p2pネットワークスパイスればトランザクションの送信者を特定できる
Dandelion++ たんぽぽ
txの発信起点の難読化
txの伝播をstemフェーズとfluffフェーズで分ける
stemフェーズ 茎
起点ノードのIPアドレスを秘匿化
継続と移行は確率的に判断
デフォルトでは90％継続
fluffフェーズ 綿
txの拡散を担当
ブロックチェーン特有の攻撃集
p291